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DESCRIPTION 61 " Cn 

f 3. Dez. 2QQZ 

System and method for context-based serialization of 
messages in a parallel execution environment 

Field of the invention 

The present invention relates generally to Messaging, and more 
particular relates to Messaging in a parallel execution 
environment . 

The term Messaging as used in this patent application may be 
defined as a method that allows two entities to communicate by 
sending and receiving messages without requiring human 
interaction. One of the most important aspect of Messaging is 
its asynchronous nature - the sender of the message does not 
have to wait for recipient to receive the information. Sending 
applications are free to generate messages at an appropriate 
speed, handling peaks periods as they occur, without having to 
wait for recipients to deal with the requests. 

Messaging methods vary in their implementations. The two most 
common implementations are the Hub- and -spoke architecture and 
the Bus architecture. 



In a Hub-and- spoke architecture, all applications are connected 
to a central process, called Message Server. The Message Server 
handles all communication among the connected applications, 
called the application client. 



The Message Server is responsible for routing messages 
correctly, authenticating and authorizing user access, and 
guaranteeing the delivery of the message. Each application 
client can either be a sender of a message, a recipient of both. 
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In a Bus architecture, there is no centralized Message Server to 
coordinate the distribution of messages. Instead, each 
application client contains the functionality typically found in 
a Message Server. All application clients are connected to a 
message bus, typically the network layer of the IP multicast 
protocol. This multicast network layer routes messages among 
each of the application clients, but the clients must perform 
all checks and balances to ensure that the message is delivered 
securely and reliably. 

One of the major problems of all Messaging methods relate to the 
execution of related requests in a parallel execution 
environment. For example, a client sends a payment message 
request to the bank (see FIG.1A). If a client sends another 
request immediately following the payment request which relates 
to the payment request, e.g. modify or cancel of the payment 
request, the messaging method must ensure that the original 
sequence of requests must be maintained in order to guarantee a 
consistent execution. In a sequential execution environment 
there is no problem since all requests are executed accordingly 
their original sequence. However in a parallel execution 
environment, e.g. the target system having two or more 
processors, it cannot be guaranteed the context-based sequence 
even if only one execution system is provided to the request 
message queue (see FIG. IB) . The parallel execution system 
starts a new thread for each incoming message request and 
executes the requests without ensuring the context-based 
sequence of ..the incoming requests. This may cause a reversed 
execution of two related consecutive requests, e.g. request to 
cancel a payment request may be executed before the payment 
request (see FIG. 1 A). That means that the request, to cancel 
the payment request fails because there is nothing to cancel and 
the payment request goes through anyway. 
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The existing prior art messaging systems, e.g. IBM MQ Series, do 
not provide any functionality for processing of context-based 
requests in parallel execution environment without human 
interactions . 

It is therefore object of the present invention to provide an 
improved messaging system and method which is also applicable in 
a parallel execution environment and which guarantees the 
automatic execution of related requests according their context- 
based or original sequence without human interaction. 

This object is solved by the features of the independent claims. 
Further advantageous embodiments of the present invention are 
laid down in the dependent claims. 

Summary of the invention 

The present invention discloses an improved messaging system and 
method which allows parallel execution of related requests 
according their context-based sequence by using a Serialization 
Processor. The Serialization Processor receives each incoming 
message request from the messaging client, retrieves the 
Transaction Identifier (TI) , checks a State Table for retrieved 
TI, and in the case the same TI is already stored in the State 
Table with the state "active" the Serialization Processor stores 
the new requests with the same TI in the serialization queue and 
makes an new entry for that TI with the state, "queued" in the 
State Table. After execution of the active request its entry in 
the State Table is cleared and the queued request with the same 
IT is executed by the execution system and its entry is updated 
from the state "queued" to the state "active". In a preferred 
embodiment of the present invention the header of message 
requests contains an Identifier (MI) which marks the message 
requests as context-based serializable . Message requests without 
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having that Identifier are executed without involvement of the 
Serialization processor. 

These and additional features and advantages of the present 
invention will become more apparent from the detailed 
description set forth below when taken in conjunction with the 
drawings . 

Brief description of the Figures 

The accompanying drawings, which are incorporated herein and 
form a part of the specification, illustrate embodiments of the 
present invention and, together with the description, further 
serve to explain the principles of the embodiments of the 
present invention. 

FIG.l A/B shows an example of the execution of related payment 
message requests with prior art messaging systems in a parallel 
execution environment, 

FIG. 2 shows a prior art messaging architecture with the present 
invention, 

FIG. 3 shows a typical hub-and- spoke messaging system where 
multiple clients put their messages to a server input queue 
which may be the basis for the present invention, 

FIG. 4 shows the typical message layout as required by the 
inventive Serialization Processor, 

FIG. 5 shows an example of message header of the message system 
of IBM MQ Series, 

FIG. 6 shows the typical message queue layout as used by the 
inventive Serialization processor, 
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FIG. 7 shows the preferred structure of the state table as used 
by inventive Serialization Processor, and 

FIG. 8 shows a floating diagram with the inventive method steps 
of the Serialization Processor. 

FIG. 2 shows a prior art messaging architecture with the present 
invention. 

The following minimum hardware and software requirements are 
needed for the implementation of the present invention: 
At the Client side a Messaging Client must be installed, e.g. 
IBM MQ Series Client. Furthermore a network connection to the 
Server System is needed. Finally, an operating system depending 
on the clients needs to be installed. If the client is a PC 
based system Microsoft Window 2 000 would be an option. 

At the Server side a Messaging Server needs to be installed 
(e.g. IBM MQ Series Server) and additionally an appropriate 
Queue Manager created and configured. A State Table as proposed 
by the present invention is implemented using a data base 
management system, e.g. IBM DB2 . The server must have installed 
a multi-tasking operating system like Windows 2000. Finally the 
inventive Serialization Processor is needed. 

Multiple clients, especially Messaging clients 1 - n 10 put 
their message requests 12 to a Server Input Message Queue or 
Request Queue 14 which is managed by the Queue Manager (see FIG. 
3) which stores the incoming messages in its Messaging Queue. If 
the message header of an incoming message defines that message 
as persistent, the message is then stored persistent, otherwise 
it is stored non-persistent. Non-persistent messages reside in 
the memory only and may get lost if the Queue Manager crashes. 
Persistent Messages are stored on a disk medium and cannot get 
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lost. Each Client needs a Client Interface Layer in order to 
communicate with the Queue Manager at the server side. 
The inventive Serialization Processor 16 gets each message 12 
from the Request Queue or Messaging Queue 14. It analyses its 
message context content in order to find the Transaction 
Identifier (TI) if the message context indicates that the 
message is of that type. The Transaction ID may be defined as" an 
Identifier in a message which identifies all messages belonging 
to the same business transaction. Then the Serialization 
Processor 16 searches in a so called State Table (ST; 18) which 
is preferably realized as a table in a database system. The 
State Table provides state information which messages are being 
"queued" or "active (executed)". The query returns two possible 
results : 

The Transaction ID cannot be found in the State Table 

In this case the Serialization Processor 16 creates a new entry 
in the State Table 18 which contains the new Transaction ID and 
the state "active". Then the Serialization Processor 16 puts the 
message into either Execution Queue 1 or 2 . The message is then 
executed by one of the threads of the connected execution system 
1 or 2. When the thread is finished with the processing and 
before it closed, the Transaction ID will be cleared in the 
State Table 18. 

The Transaction ID is found in the State Table 18 with the state 
"active" 

In this case the new message will be put to the new introduced 
Serialization Queue 20. In this Queue 20, the message is hold 
until the active thread has finished and has cleared the 
Transaction ID in the State Table 18. If further message arrives 
in the Request Queue 14 which have the same Transaction ID, 
these will be put to the Serialization Queue 20. 
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The Serialization Processor 16 has to check in certain intervals 
for messages hold in the Serialization Queue 20. There may be 
different mechanisms to cause the Serialization Processor 16 to 
do this check. One method is to set a timer interval, and 
whenever the timer interrupt occurs the Serialization Processor - 
16 checks the messages in the Serialization Queue 20. Another 
method would be that the executing threads sets a semaphore to 
inform the Serialization Processor 16 that it has finished its 
task and has cleared the Transaction ID in the State Table 18 . 
If the Serialization Processor 16 is triggered by such an event/ 
it checks for any messages in the Serialization Queue 20, and if 
one is found, checks the Transaction ID has already been cleared 
from the State Table 18. If the Transaction ID has been cleared, 
the message is removed from the Serialization Queue 2 0 and put 
to one of the Execution Queue s for processing. 

Another embodiment of the present invention when the Transaction 
,ID is found in the State Table 18 with the state "active" may be 
implemented as follows: 

In this case the new message will be put to the new introduced 
Serialization Queue 20 and a new entry for that new message is 
created in the State Table 18 with the status "queued". After a 
defined time interval the Serialization Processor 16 checks the 
State Table 18 and puts the messages entries with the state 
queued to the state "active" when their related messages with 
the entry "active" have been cleared. 

FIG. 3 shows a typical hub- and- spoke messaging system where 
multiple clients 10 put their messages to a Server Input Queue 
or Message Queue 14 . Each client 10 needs a client interface 11 
with the Queue Manager 15. Furthermore, the inventive 
Serialization Processor (not shown) has an interface with the 
Queue Manager as well as the application system. The 
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Serialization Processor ensures that an application thread is 
assigned to a message only when the Serialization Processor puts 
the message to the Execution Queue of the appropriate 
application 17. 



FIG. 4 shows the typical message layout as required by the 
inventive Serialization Processor. " 

The message 12 consists of a message header 24 and a message 
body 26. The message header 24 normally contains the Message 
Identifier, the Source Queue Name, the target Queue Manager, the 
target Queue Name, the message type, and the code page used for 
the Message Body. Messages without a non-context-based 
Identifier are basically defined as non-related and therefore do 
not need to be executed by using the inventive Serialization 
Processor. The message body 26 normally contains the Transaction 
Identifier and the user (application) defined data. The message 
body 2 6 is basically not handled by the messaging system but by 
the execution or application system. It is free defined by the 
connected applications, and the content is unknown to the 
messaging system. 

This means that the message system itself cannot react on a 
Transaction ID which is part of the message body 26. Therefore, 
the Transaction ID is inspected by the Serialization Processor 
in order to avoid parallel execution for two messages which 
belong to the same Transaction Identifier. FIG. 5 shows as an 
example a message header of the message system IBM MQ Series 
which may be used by the present invention. 

FIG. 6 shows preferred embodiment of the Request or Message 
Queue as used by the present invention. 



Messages are put into the queue from clients. On the right side, 
messages are taken out by the Serialization Processor at the 
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server side. In the inventive message system as described in 
this patent application, each message taken out of the queue 
creates a new application thread which handles the body of the 
message. There may be multiple server machines connected to the 
same queue, taking the messages in parallel. 

FIG. 7 shows a preferred embodiment of the State Table as used 
by the present invention. 

Each incoming new message request contains a Transaction ID 28 
in its message body. The Serialization Processor checks the 
State Table 18 whether this Transaction ID 28 is already stored, 
and whether the Transaction State 3 0 is active. If yes, the 
Transaction ID 28 together with the State 3 0 "queued" and the 
Message ID 3 3 taken out from the Message header is stored in the 
State Table 18 together with a Time Stamp 3 6 defining the 
arrival time of the new message. The State Table 18 may be 
preferably implemented as a persistent table in a data base 
system comprising the columns Transaction ID, Message ID, and 
Time Stamp. This guarantees that no message can get lost. 

If an incoming message request contains a Transaction ID 28 
which is not found in the State Table 18, the new Transaction ID 
28 is stored in the State Table 18 with the state 30 "active", 
together with its arrival time (Time Stamp 36) and the Message 
ID 33 from the message header. Then the message is delivered to 
an application thread for processing. When the tread has 
completed its processing, the entry will be cleared from the 
State Table 18. 

Possible Transaction States 3 0 in the State Table are: 

Active - This indicates that a message with the same Transaction 
ID 28 is currently processed by one of the application threads 
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Queued - This indicates that a message with the same Transaction 
ID 28 is already queued, and is waiting for processing. The new 
message will also be queued. 

The Message ID 33 may also be stored in the State Table 18. It 
is needed later in order to retrieve the correct message from - 
the Serialization queue when the processing of the active 
transaction is finished. 

Furthermore, the Time Stamp 36 of the arrival time of the 
message is needed in the case more than one entries with the 
same Transaction ID 28 are found in the State Table 18. In this 
case, the saved messages must be put to the application queues 
in the sequence they have arrived. 

To make sure that no request ever gets lost, a Logical Unit of 
Work (LUW) must span all activities necessary to process a 
message. A LUW will be started when a message is received from 
the Request Queue. Then the data base holding the State Table 18 
is accessed to query for the Transaction Identifier 28, after 
the message is put to one of the Execution Queue s. The State 
Table 18 will be updated to reflect the new Transaction ID 28. 
Then the Commit must be issued which commits all activities. 
This guarantees that the message now is deleted from the Request 
Queue, it will be available for processing in the Execution 
Queue , and the Transaction ID is stored in the State Table. The 
same transaction processing must be performed when a saved 
message is taken out from the Serialization Queue and send to 
one of the Execution Queue s for processing. 

FIG. 8 shows a floating diagram with the inventive method. 
The client application may be for example a payment application. 
The user creates with this payment application a payment message 
with contains following data: amount of money to be paid, 
sender, receiver. Transaction ID. The payment application 
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creates with the means of the Message Client a payment message 
100. The payment message contains a Message header and message 
body (see explanation to FIG. 5) . The payment message is sent to 
the Message Server by means of the Message Client and the 
network 150. The Message Server receives that payment message 
and puts the payment message in an Input Queue by means of the 
Queue Manager 200. The Queue Manager stores that payment message 
persistent or non-persistent depending on the data in the 
message header. The Serialization Processor takes out the 
payment message from the Input Queue 250 , analyses the payment 
message for the Transaction ID 300, searches in the State Table 
for the same Transaction ID 350, and if the Transaction is not 
already contained in the State Table 400, the Serialization 
processor creates a new entry in the State Table with the 
Transaction ID of the new message, its Message ID, its Time 
Stamp and its state "active" 500 and puts the payment request to 
execution system for processing of that payment message 600. If 
the payment message is executed by the execution system or 
application the entry in the State Table will be cleared 700. 
In the case the Transaction ID is already stored in the State 
Table 450, the Serialization processor puts . the .new. paymenjt . .. 
message into the Serialization queue 550 and when the same 
Transaction ID has been cleared in the State Table the 
Serialization Processor puts the payment message to the 
execution system for processing 650. In another embodiment of 
the present invention the new message will be put to the new 
introduced Serialization Queue and a new entry for that new 
message is created in the State Table with the status "queued" . 
After a defined time interval the Serialization Processor checks 
the State Table and updates the message entry with the state 
queued to the new state "active" when their related message with 
the entry "active" has been cleared. 
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Messaging System for context-based serialization of 
messages in a parallel execution environment comprising a 
Serialization Processor for receiving incoming messages 
from said Message Client, extracting the Transaction IDs 
contained in said messages, checking a State Table for the 
same Transaction IDS, putting said messages into a 
Serialization Queue if said same Transaction IDs are 
already stored in said State Table with the state w active", 
and putting said message into an Execution Queue if the 
entry with the same Transaction ID has been cleared in said 
State Table. 



Messaging System according to claim 1, wherein said 
Serialization Processor creates a new Transaction ID entry 
in said State Table for incoming messages with the state 
"queued" if the same Transaction ID with the state "active" 
is already stored in said State Table and puts the new 
message to the Serialization Queue. 

Messaging System according to claim 1, wherein said 
Serialization Processor creates a Time Stamp entry in said 
State Table, wherein said Time Stamp defines the arrival 
time of said message and the Serialization Processor puts 
the messages into the Execution Queue according to their 
temporal sequence . 

Messaging System according to claim 1, wherein said 
Serialization Processor creates a Message ID entry in said 
State Table, wherein said Message ID is used by said 
Serialization Processor to retrieve the Messages from the 
Serialization Queue. 
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5. Server System comprising a Messaging Server communicating 
wxth a messaging client, a Queue Manager for managing the 
Message Queue at the server side, an execution system 
allowing parallel processing of messages, a network 
connection between Server System and client System, wherein 
said Server System is characterized by the further 
components : 

a Serialization Queue for qfoHnrr *-i 

v ior s t°rxng the messages to be 

queued, 

an Execution Queue for storing the messages to be executed, 

a State Table providing state information which messages 
are being "queued" or "executed", 

a Serialization. Processor for automatically putting the 
messages from said Message Queue in said appropriate queues 
based on said state information contained in said State 
Table and updating said State Table accordingly. 

6. Server System according to claim 5, wherein said State 

Table comprises at least the Transaction ID of the message 
and xts current state, wherein said current state may be 
"active" or "queued". 

7- Server System according to claim 6, wherein said State 

Table additionally comprises a Time. Stamp for each message 
whxch defines the arrival time of said message 



8. Server System according to claim 7, wherein said State 

Table additionally comprises a Message ID for each message 
for retrieval of the messages from the Serialization Queue 
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9. Server System according to claim 5, wherein said 

Serialization Processor receives the incoming messages from 
said Message Client via said Message Queue, retrievesreads 
out the Transaction IDs contained in said messages, checks 
said State Table for the same Transaction IDs, puts said 
message into a Serialization Queue if said same Transaction 
IDs is already stored in said State Table with the state 
"active", and puts said message into an Execution Queue if 
the entry with the same Transaction ID has been cleared in 
said State Table. 

10. Server System according to claim 9, wherein said 

Serialization Processor creates a new entry in said State 
Table with the new Transaction ID and the state "queued" if 
the same Transaction ID with the state "active" is already 
stored in said State Table. 

11. Method for context-based serialization of messages in a 
Server System having Server Input Queue and an execution 
system which allows parallel processing of messages, 
comprising the steps of: 

retrieving^ new message from the Server Input Message 
Queue , 

analyzing said new message to find their Transaction ID, 

searching State Table for said found Transaction ID, 

creating a new entry in said State Table with its 

Transaction ID and its state "active" of said new message 

if said State Table does not contain the same Transaction 
ID, and 



putting said new message into the Execution Queue. 
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12. Method for automatic context-based serialization of 

messages in Server System having an execution system which 
allows parallel processing of messages, comprising the 
steps of: 

retrieving a new message from the Server Input Message 
Queue, 

analyzing said new message to find its Transaction ID, 

searching State Table for said found Transaction ID of said 
new message, 

putting said new message into a Serialization Queue if said 
State Table already contains the same Transaction ID with 
the state "active". 



13. Method according to claim 12 further comprising the steps 
of: 



creating a new entry in said State Table with the 
Transaction ID of the new message and its state "queued", 

putting said new message to the Execution Queue when said 
Transaction ID with its state "active" has been cleared in 
said State Table. 



14. Method according to claim 12, further comprising the step 
of: 



checking in defined time intervals the state of said 
messages in said State Table 
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putting a message from the Serialization Queue into the 
Execution Queue if the message with the same Transaction ID 
has been cleared in said State Table. 

15. Method according to claim 11, wherein said creating step 
further comprising the step of: 

assigning a Time Stamp to said Transaction ID in said State 
Table which defines the arrival of said new message 

putting said new messages into the Execution Queue 
according their temporal sequence. 

16. Method according to claim 12, wherein said creating step 
further comprising the step of: 

assigning a Message ID to said Transaction ID in said State 
Table, 

retrieving said message via said Message ID from the 
Serialization Queue. 

17. Computer program product stored in the internal memory of a 
digital computer containing parts of software code to 
execute the. method in accordance with claims 11 to 16 if 
the product is run on the computer. 
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1 3. Dezo 2002 

System and method for context -based serialization of 
m ssages in a parallel execution nvironment 

The present invention discloses an improved messaging system and 
method which allows parallel execution of related requests 
according their context-based sequence by using a Serialization 
Processor. The Serialization Processor receives each incoming 
message request from the messaging client, extracts the 
Transaction Identifier (TI) , checks a State Table for the 
extracted TI, and in the case the same TI is already stored in 
the State Table with the state "active" the Serialization 
Processor stores the new requests with the same TI in the 
serialization queue and makes an new entry for that TI with the 
state "queued" in the State Table. After execution of the active 
request its entry in the State Table is cleared and the queued 
request with the same IT is executed by the execution system -and 
its entry is updated from the state "queued" to the state 
"active" . In a preferred embodiment of the present invention 
the header, of message requests contains an Identifier which 
marks the message requests as context-based serializable. 
Message requests without such Identifier are executed without 
involvement of the Serialization processor. 
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